So 24. Nov 2019, 14:23 Wow, starke Sache. Ich hoffe, das kommt auch bis zur Serienrealisierung, wäre schön, denn es würde ja einen wohl einfachen Weg ins www für unsere A8 bringen.
Gruss, Holger
_______ Ressortleiter Software. Link zu meinen eigenen Programmen: http://demozoo.org/sceners/44561/
von tschak909 » Di 26. Nov 2019, 07:12 Hey, guys.
I'm the guy writing the firmware behind #FujiNet, and can answer any questions anyone may have about it. 🙂
-Thom
vollständig aus dem alten Forum übertragen
Alle Atari-Programme streamen via Web?
https://atariage.com/forums/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/
Oder sitze ich schon zu lange am Rechner...
Schöne Grüße, Luckybuck Atari WIKI, Atarimania & Archive.org
von tschak909 » Di 26. Nov 2019, 18:02
luckybuck hat geschrieben:
*Das und PLATO, genau dafür bietet Thom uns ja seine Hilfe an! 🙂
Jetzt aber :beer:*
Thanks, Roland.
I hope posting in English is okay? If not, please let me know.
At this moment:
On the last point, if there are any in the ABBUC who have insight into writing a CIO handler, I need to hear from you. I am having difficulty making CIO GETREC work properly, and need to understand its behavior, as well as other bits of behavior that are otherwise not documented, because at the moment, I am literally writing small tests, and observing their behavior by writing test programs in BASIC.
But to answer the question, can you write a CIO driver in CC65? yes. Is it efficient code? no. 🙂 but that's okay, once it is written, it can be translated to assembler by someone more competent. 🙂
-Thom
von luckybuck » Di 26. Nov 2019, 17:06 Das und PLATO, genau dafür bietet Thom uns ja seine Hilfe an! 🙂
Jetzt aber :beer:
Schöne Grüße, Luckybuck Atari WIKI, Atarimania & Archive.org
von tschak909 » Sa 30. Nov 2019, 04:07 Ok guys, for those of you who REALLY KNOW #Atari SIO and handler loading, I need help:
I have checked in a new test:
https://github.com/tschak909/atariwifi/ ... /cio4-poll
Which literally tries to utilize the Atari 850 handler bootstrap method to load in the N: driver I've been developing.
So far, I have been able to:
Answer the type 1 poll, with an appropriate DCB for a loader program, that loads into a fixed location $1D00
The SIO request is honored, loader shows up at $0500, jump to $0506, which sets up ANOTHER DCB to load the handler at $1D00.
The loader then jumps to $1D01, which, ultimately goes into a loopty-loop, as AUTORUN.SYS gets loaded over and over again with a corresponding long beep.
I have tried to daisy chain DOSINI by saving it at the beginning of main(), setting a new DOSINI value (to point to my main()), and then jumping to the value I saved. but it loops.
Really wanna know why. Because this has kicked my arse, every step of the way, all day.
(and no, the 850 source code isn't much help, it's a highly compressed bowl of pasta in the expediency of conserving ROM space)
von luckybuck » Di 26. Nov 2019, 18:10 No Problem Thom, you are welcome at any(!) time! 🙂
A CIO driver in CC65 is sadly beyond my capabilities as of this moment. But there should be enough members, who can do this best to your needs, I am sure.
Denke, dass es O. K., wenn Thom in englisch schreibt. Neben dem Google-Translator gibt es ja noch:
Das mit künstlicher Intelligenz arbeitet und nicht nur englische Texte übersetzen kann. Habe das unten mal für den Post von Thom gemacht. Darüber hinaus kann man rechts oben unter "Sprache auswählen" ja auch in andere Sprachen übersetzen lassen. 🙂
Danke, Roland.
Ich hoffe, dass die Veröffentlichung auf Englisch in Ordnung ist? Wenn nicht, lassen Sie es mich bitte wissen.
In diesem Moment:
Zum letzten Punkt: Wenn es im ABBUC welche gibt, die Einblicke in das Schreiben eines CIO-Handlers haben, muss ich von Ihnen hören. Ich habe Schwierigkeiten, CIO GETREC richtig funktionieren zu lassen, und muss sein Verhalten sowie andere Verhaltensweisen verstehen, die ansonsten nicht dokumentiert sind, denn im Moment schreibe ich buchstäblich kleine Tests und beobachte ihr Verhalten, indem ich Testprogramme in BASIC schreibe.
Aber um die Frage zu beantworten, können Sie einen CIO-Treiber in CC65 schreiben? ja. Ist es effizienter Code? nein. 🙂, aber das ist in Ordnung, sobald er geschrieben ist, kann er von jemandem, der kompetenter ist, in Assembler übersetzt werden.)
-Thom
Schöne Grüße, Luckybuck Atari WIKI, Atarimania & Archive.org
von tschak909 » So 1. Dez 2019, 09:52
von luckybuck » Mo 2. Dez 2019, 03:32
Sleeπ
von tschak909 » Do 12. Dez 2019, 18:59 Es scheint sehr ruhig hier drin zu sein.
-Thom
Sleeπ
von tschak909 » Do 12. Dez 2019, 20:28 Ja, aber ich habe auch anderen geholfen, die ihre eigenen bauen. Der Schaltplan für das Interface-Board befindet sich im AtariAge-Thread.
-Thom
Sleeπ
von tschak909 » Do 12. Dez 2019, 20:42
Hier ist der aktuellste Schaltplan:
Ich bin ehrlich gesagt mehr daran interessiert, dass Leute diese Hardware einsetzen, als Tonnen von Geld damit zu verdienen.
-Thom
Sleeπ
von luckybuck » So 22. Dez 2019, 01:08 Das ist absolut phantastisch Thom!
Riesenleistung! :notworthy:
Freue mich schon darauf, wenn wir die Hardware dazu haben. 🙂
Schöne Grüße, Luckybuck Atari WIKI, Atarimania & Archive.org
von luckybuck » Sa 14. Dez 2019, 02:16 Cool!
Sleeπ
von tschak909 » Mo 23. Dez 2019, 07:02
Ich habe die Midi-Labyrinth-Skizze, die @mozzwald zusammengesetzt hat, in ein voll funktionsfähiges Testprogramm geworfen, das eine Midi-Labyrinth-Verbindung zwischen zwei Endpunkten aufbaut. Ein paar SIO-Befehle wurden hinzugefügt, um die erforderliche Einrichtung zu unterstützen, und ich habe das Ergebnis an @mozzwald weitergegeben. Der Code ist hier: https://github.com/FujiNetWIFI/atariwifi/tree/master/esp32/tests/midimaze
@mozzwald hat meinen Code genommen und ihn zur Arbeit optimiert. ESP32 verwendet eine völlig andere API, um PWM-Takte zu machen, und selbst mit den erforderlichen Änderungen (und einem korrekten Taktsignal) haben wir Timing-Probleme, die dazu führen, dass das Spiel nicht funktioniert. Der gleiche Code funktioniert auch auf dem 8266.
Ich habe ein neues cio-Testprogramm geschrieben, um die UDP-Kommunikation zu üben, das noch zu debuggen ist, es ist hier: https://github.com/FujiNetWIFI/atariwifi/tree/master/esp32/tests/cio6-udp
Wir haben bemerkt, dass das serielle Timing des ESP32 langsamer ist als das des 8266. Es gibt definitiv Verzögerungen bei der Übertragung von Daten, die weitreichende Auswirkungen haben, von der langsamen Leseperformance (Schreiben, ist irgendwie schneller!), bis zu der Tatsache, dass Midimaze nicht läuft.
Wir brauchen definitiv mehr Hilfe, um diese Zeitprobleme aufzuspüren, da sie die Zuverlässigkeit beeinträchtigen (und wenn man es am wenigsten erwartet!)
Wenn Sie also Erfahrungen mit ESP8266/ESP32 unter Arduino haben, schauen Sie sich bitte an, was wir haben, um zu sehen, was besser gemacht werden kann.
-Thom
Sleeπ
von tschak909 » Do 26. Dez 2019, 20:37 Und kann jemand einen besseren Diskulator schreiben? Der aktuelle Diskulator ist hier:
https://github.com/FujiNetWIFI/atariwifi/tree/master/esp32/tests/multilator/atari
Die Liste der aktiven Befehle ist hier: https://github.com/FujiNetWIFI/atariwifi/wiki/SIO-Commands-for-Device-ID-%2470
Sie können den gesamten Ablauf sehen, wie man Befehle an FujiNet sendet, um Dinge wie
und sogar Dinge wie
All diese Dinge folgen dem gleichen Grundmuster:
der Multilator ist auch eine Fallstudie, wie man eine Boot-Diskette aus einer CC65-Binärdatei erstellt (die sehr hackige Art, die Standard-Binärdatei-Header und -Segmente zu entfernen und einen Boot-Loader-Header am Anfang von crt0.s hinzuzufügen)
Es ist am Ende des Tages ein Beispiel. Ich habe CC65 benutzt, weil ich mich damit wohl fühle.
Wenn Sie einen in Assembler machen wollen, machen Sie bitte weiter. Mehr Beispiele für jeden.
Wenn Sie es in ACTION machen wollen! Sicher. Noch mal, gleiche Prämisse?
BASIS? Ja, da wird es auch funktionieren.
Ich frage das, weil ich weiterhin Features und Funktionen ausarbeiten muss und ich möchte mehr Leute dazu bringen, etwas besser zu schreiben, als ich es kann.
-Thom
Sleeπ
von tschak909 » Fr 27. Dez 2019, 09:43
"Diskulator" is what I call the D: emulation.
It allows for a disk image (.ATR) to be mounted from a server on either the local network, or internet, and used as if it were a local disk.
The network protocol used is called TNFS, which is a simplified networking protocol intended to serve files to 8-bit systems over UDP. We have borrowed this from the Spectranet project (which is a network adapter for ZX Spectrum machines) since it is very computer agnostic.
In the context of the latest test, Multi-lator provides up to 8 of these virtual disk slots (emulating D1: to D8) that are able to be mounted from the network, each can even be mounted from different hosts.
So, for example:
D1: could be Spartados3.2d.atr mounted from irata.online D2: could be games.atr also mounted from irata.online D3: could be empty, meaning a local disk, a 1050, an SDrive, whatever, D4: to D8: could also be empty
As far as the Atari is concerned, it is reading and writing to a disk drive. What it does not know is that the disk could be thousands of miles away, or it could be across the room on your local network. It does not matter.
I deliberately designed this aspect of functionality specifically so that every single Atari user would have a use for #FujiNet, out of the box. It means that virtually every single piece of Atari software is not immediately accessible to anyone with a #FujiNet. This is not hyperbole, especially in light of the fact that TNFS is merely one way that disk images can be mounted. I am also working on the ability to mount disk images over HTTP and HTTPS. This is also, only one aspect of #FujiNet's intended functionality.
To recap:
This is to say nothing of:
Do you see what I'm after? 🙂
-Thom
"Diskulator" ist das, was ich die D: Emulation nenne.
Sie ermöglicht es, ein Disk-Image (.ATR) von einem Server im lokalen Netzwerk oder im Internet zu mounten und wie eine lokale Festplatte zu verwenden.
Das verwendete Netzwerkprotokoll heißt TNFS, ein vereinfachtes Netzwerkprotokoll, das dazu gedacht ist, Dateien an 8-Bit-Systeme über UDP zu verteilen. Wir haben es vom Spectranet-Projekt (das eine Netzwerkkarte für ZX Spectrum-Maschinen ist) geliehen, da es sehr computerunabhängig ist.
Im Rahmen des letzten Tests stellt Multi-lator bis zu 8 dieser virtuellen Diskettenschlitze (emuliert D1: bis D8) zur Verfügung, die vom Netzwerk aus gemountet werden können, jeder kann sogar von verschiedenen Hosts aus gemountet werden.
So kann zum Beispiel
D1: könnte Spartados3.2d.atr von irata.online gemountet werden. D2: könnte games.atr auch von irata.online gemountet sein D3: könnte leer sein, d.h. eine lokale Festplatte, ein 1050, ein SD-Laufwerk, was auch immer, D4: bis D8: könnte auch leer sein
Was den Atari betrifft, so liest und schreibt er auf ein Laufwerk. Was er nicht weiß, ist, dass die Festplatte Tausende von Kilometern entfernt sein kann, oder dass sie quer durch den Raum in Ihrem lokalen Netzwerk liegen kann. Das spielt keine Rolle.
b] Ich habe diesen Aspekt der Funktionalität bewusst so gestaltet, dass jeder einzelne Atari-Benutzer sofort eine Verwendung für #FujiNet hat. Das bedeutet, dass praktisch jedes einzelne Stück Atari-Software nicht sofort für jemanden mit einem #FujiNet zugänglich ist. Das ist keine Übertreibung, besonders im Hinblick auf die Tatsache, daß TNFS nur eine Möglichkeit ist, Disketten-Images zu mounten. Ich arbeite auch an der Möglichkeit, Disk-Images über HTTP und HTTPS zu mounten.[/b]
Dies ist auch nur ein Aspekt der beabsichtigten Funktionalität von #FujiNet.
Um es zusammenzufassen:
Das tut nichts zur Sache:
Sehen Sie, was ich will?
Sleeπ
von tschak909 » Fr 27. Dez 2019, 09:45 The current code is here: https://github.com/FujiNetWIFI/atariwifi
with the latest multilator in tests/esp32/multilator
Sleeπ
von tschak909 » Fr 27. Dez 2019, 18:25 I understand, am just trying to get people interested, and even looking at the schematics for what we have and building some units. 🙂
-Thom
Sleeπ
von Mark » Sa 28. Dez 2019, 15:08 Hallo
Gibt es irgendetwas sinnvolles für dieses gerät....
Hab es mal nachgebaut,die hälfte von den "test" Ordner funktioniert nicht. Ausserdem verträgt sich bei mir die Hardware nicht mit anderer Hardware zur selben zeit am sio bus wenn man bootet.Muss das cmd signal entfernen und nach dem booten von "autorun.sys" wieder anstecken. ????
gruss
Sleeπ
von tschak909 » Di 31. Dez 2019, 23:46 https://youtu.be/ZW07ZaNKMdY
Hey Leute, es ist das Ende des Jahres. Ich hoffe, alle hatten einen guten Tag.
Ich habe dieses #FujiNet-Video aufgenommen, um die Verbesserungen der Zuverlässigkeitsleistung zu zeigen, die in der letzten Woche im Multilator gemacht wurden, die sogar über Links zu Cloud-Hosts fantastisch sind!
In diesem Video kopieren wir ein Disk-Image auf eine echte Atari 1050-Diskette, ebenso wie auf ein anderes Disk-Image, auf einen anderen Cloud Host und booten diese!
Hey guys, it's the end of the year. Hope everyone's had a good one!
I've recorded this #FujiNet video to show the reliability performance improvements that have been made in Multilator over the last week, which are fantastic even over links to cloud hosts!
In this video, we copy a disk image TO a real Atari 1050 disk, AS WELL as to another disk image, on ANOTHER cloud host, and boot them!
-Tho
Sleeπ
von tschak909 » So 5. Jan 2020, 02:48 Hier sind zwei Updates!
Die Ergebnisse seines Codes wurden in die PlatformIO-Firmware gefaltet, die sich im github-Repository befindet.
Bild
Es gibt noch viel zu tun mit diesem, wie z.B. die Implementierung von Typ 1 SIO-Polling, aber es kommt ziemlich gut voran, und du kannst es hier sehen:
https://www.youtube.com/watch?v=W9jKa9GGHqM
Here are two updates!
The results of his code have been folded into the platformIO firmware that is in the github repository.
Bild
There's still a lot to be done with this one, such as implementing type 1 SIO polling, but it is coming along quite nicely, and you can see it here:
Sleeπ
von tschak909 » So 19. Jan 2020, 02:33 Thanks to help from Montezuma, we have high-speed working, even all the way up to POKEY divisor 0! (125kbps!)
Sleeπ
von luckybuck » So 19. Jan 2020, 03:13 😀 😀 😀 😀 😀
Sleeπ
von tschak909 » Sa 25. Jan 2020, 00:46 This test shows the possibility of using the N: (network) device for file-level HTTP GET requests. This is implemented using a CIO handler loaded at boot via AUTORUN.SYS. It works well enough to load BASIC programs!
https://www.youtube.com/watch?v=9GakIrw5pK4
Dieser Test zeigt die Möglichkeit, das N: (Netzwerk-)Gerät für HTTP-GET-Anforderungen auf Dateiebene zu verwenden. Dies wird mit Hilfe eines CIO-Handlers implementiert, der beim Booten über die AUTORUN.SYS geladen wird. Er funktioniert gut genug, um BASIC-Programme zu laden!
Sleeπ
von dl7ukk » Sa 25. Jan 2020, 18:48 Hello Thom,
the CIO handler "N:" has been used before. For the device "Null" (like Linux /dev/null).
Here is the source
.OPT NUM
0110 .TITLE "Null Device Handler" 7/31/86
0120 ;
0130 ;
0140 ;
0150 ; (C) 1986 by Paul B. Loux
0160 ;
0170 ; Permission is granted to
0180 ; distribute on a non-profit
0190 ; basis provided that this
0200 ; header remains.
0210 ;
0220 ;
0230 ; Null Device handler, installs
0240 ; a device "N:" into the device
0250 ; handler table. The null device
0260 ; is a no-op handler useful for
0270 ; for debugging I/O routines.
0280 ; It always returns a status
0290 ; of "1" (no error), and the
0300 ; Accumulator is loaded with
0310 ; $9B (return) to facilitate
0320 ; record I/O through CIO. The
0330 ; handler supports all CIO and
0340 ; XIO command types, and
0350 ; occupies only 82 bytes. It
0360 ; protects itself from RESET.
0370 ;
0380 ;
0390 ;
0400 ; System Equates
0410 ; ______________
0420 ;
0430 DOSVEC = $0A
0440 DOSINI = $0C
0450 SPBYT1 = $CB
0460 SPBYT2 = $CC
0470 RUNAD = $02E0
0480 INITAD = $02E2
0490 SAFETY = $02F5
0500 MEMLO = $02E7
0510 HATABS = $031A
0520 COLDSV = $E477
0530 ;
0540 ;
0550 ; Re-install Code
0560 ; _______________
0570 ;
0580 ; (keep RESET-proof)
0590 ;
0600 *= $1EA1
0610 START
0620 JSR $FFFF
0630 SETVEX
0640 LDA # <MEMADJ
0650 STA MEMLO
0660 LDA # >MEMADJ
0670 STA MEMLO+1
0680 LDA #$FF
0690 STA SAFETY
0700 ;
0710 ;
0720 ; Vector setup
0730 ; ____________
0740 ;
0750 NSETUP
0760 LDA #'N
0770 STA TEMP
0780 LDX #$00
0790 SERCH
0800 LDA HATABS,X
0810 CMP TEMP
0820 BEQ FOUND
0830 CMP #$00
0840 BEQ FOUND
0850 INX
0860 INX
0870 INX
0880 BNE SERCH
0890 RTS ; Error
0900 FOUND
0910 LDA #'N
0920 STA HATABS,X
0930 LDA # <NDRIVER
0940 STA HATABS+1,X
0950 LDA # >NDRIVER+1
0960 STA HATABS+2,X
0970 RTS
0980 ;
0990 ; N: Vector Table
1000 ; _______________
1010 ;
1020 NDRIVER
1030 .WORD NOPEN-1 ; Open
1040 .WORD NCLOS-1 ; Close
1050 .WORD NGETC-1 ; Read
1060 .WORD NPUTC-1 ; Write
1070 .WORD NSTAT-1 ; Status
1080 .WORD NSPEC-1 ; Special
1090 .BYTE $4C
1100 .WORD NINIT ; Init
1110 ;
1120 NOPEN ; All no-ops
1130 NCLOS
1140 NGETC
1150 NPUTC
1160 NSTAT
1170 NSPEC
1180 NINIT
1190 LDA #$9B ; EOL
1200 LDY #$01 ; Success flag
1210 RTS
1220 ;
1230 ; Working variables
1240 ; _________________
1250 ;
1260 TEMP .BYTE 0
1270 INIDOS .WORD 0
1280 ;
1290 ;
1300 MEMADJ = * ; Re-set Memlo pointer
1310 ;
1320 ; Install Code
1330 ; ____________
1340 ;
1350 LOAD
1360 LDA DOSINI
1370 STA START+1
1380 STA INIDOS
1390 LDA DOSINI+1
1400 STA START+2
1410 STA INIDOS+1
1420 LDA # <START
1430 STA DOSINI
1440 LDA # >START
1450 STA DOSINI+1
1460 RTS
1470 ;
1480 ; Set Load-n-Go
1490 ; _____________
1500 ;
1510 *= INITAD
1520 .WORD LOAD
1530 *= RUNAD
1540 .WORD SETVEX
1550 ;
1560 ;
1570 ; End
1580 ; ___
1590 .END
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
n
(Magazin Antic 1989)
Screenshot Emulator
Grüße
Sleeπ
von tschak909 » Sa 25. Jan 2020, 18:56 Yup, I understand, for a programming exercise.
I do think this is a bit more useful.
-Thom
Sleeπ
von Mathy » So 26. Jan 2020, 02:44 Hello Thomas
You could use F: for "FujiNet" or "W:" for WiFi. I'd prefer "W:" as somebody else might come up with a different piece of hardware that basically does the same thing but of course has a different name.
Sincerely
Mathy
Sleeπ
von dl7ukk » So 26. Jan 2020, 03:37
Mathy hat geschrieben:
*Hello Thomas
You could use F: for "FujiNet" or "W:" for WiFi. I'd prefer "W:" as somebody else might come up with a different piece of hardware that basically does the same thing but of course has a different name.
Sincerely
Mathy*
Guter Gedanke/ Good thought, good idea "F:" für FujiNet 😀
Gruß
Sleeπ
von tschak909 » So 16. Feb 2020, 22:14 Statusbericht für 2020-02-16:
@tschak909 Überwindung der Grippe. Ich habe es geschafft, die FNC-Tools vollständig zu debuggen (FSCAN und FNET funktionieren jetzt, es gibt jetzt einen FMALL-Befehl, der nach einer FNET-Änderung alle Geräte-Steckplätze neu bestückt. Die Dokumentation wurde aktualisiert. Ich habe mich an einer hybriden DOS 2/Boot-ladefähigen Diskette mit CONFIG und den FNC-TOOLS versucht. Es funktioniert, aber die Einbaulogik muß geändert werden, damit das eingebaute Disketten-Image nicht versehentlich ausgelagert wird, wenn die Host-Liste/Geräte-Steckplätze gelesen werden (dieses Verhalten verwende ich in CONFIG).
@jeffpiep hat die Funktionalität schnell in den PlatformIO-Baum eingeklappt, und die resultierende Firmware ist nicht nur recht brauchbar, sondern auch extrem modular. Er hat gestern eine Pause eingelegt, um an seinem Beitrag für den 10-Linien-BASIC-Wettbewerb zu arbeiten.
@damosan hat jetzt seinen Ice Cream Sandwich-Prototypen und arbeitet an einer Version des verschiebbaren N: Device Handler.
Status report for 2020-02-16:
@tschak909 getting over flu. I did manage to get the FNC tools completely debugged (FSCAN and FNET now work, there is now an FMALL command which will re-mount all device slots after an FNET change. Documentation updated. I did try my hand at a hybrid DOS 2/Boot loadable disk containing CONFIG and the FNC-TOOLS. It works, but the mounting logic will need to be changed so that the built in disk image isn't accidentally swapped out when the host list/device slots are read (I use this behavior in CONFIG).
@jeffpiep Has been rapidly folding in functionality into the PlatformIO tree, and the resulting firmware is not only quite usable, but extremely modular. He paused yesterday, to work on his submission for the 10-liner BASIC contest.
@damosan now has his Ice Cream Sandwich prototype, and is working on a version of the relocatable N: device handler.
Sleeπ
von luckybuck » Sa 7. Mär 2020, 19:58 Danke Dir Thom, das ist dann 19 Uhr bis 21 Uhr lokale Zeit in Deutschland. Wäre cool! 🙂
Vielen lieben Dank, das ist ein ganz tolles Projekt! 🙂
Thank you so much Thom, highly appreciated! So, this is local time Germany 7 pm to 9 pm.
Great project! Hope, many will join. 🙂
All the best.
Sleeπ
von Mathy » So 8. Mär 2020, 01:19 Hallo Leute
Wird wohl Sonntag den 8. sein.
Tschüß
Mathy
Sleeπ
von luckybuck » Mo 9. Mär 2020, 00:07 No problem Thom, hope, everything was fine?
Btw, is there a date, when the PLATOTERM carts can be bought?
All the best,
Roland.
Sleeπ
von luckybuck » Sa 14. Mär 2020, 06:34 WOW! You are working with VSC... Do we have all 6502 plugins needed? 😉
Great work! 🙂 Thank you.
Sleeπ
von tschak909 » Sa 14. Mär 2020, 19:08 Status for 2020-03-14:
@jeffpiep is hard at work implementing the Atari 1020 plotter emulation. This emulation is unique in that the output is not PDF, but an SVG.
There are a few more testers of ESP32 boards popping up, and bug reports are coming in.
The TNFS filesystem implementation is accidentally sending back successes when all retries have been exhausted. It comes from an inconsistent mis-match of return values that happened when we ported the code to use the standard Arduino FS API. Whoops.
In addition, the TNFS retry timings need to be further tuned, as currently there are more retry attempts than there is time for in the SIO timeout allotted by the OS for most disk operations (5 retries, 5000ms, 25 seconds, compared to 15 seconds for the OS.), We need to decrease the time between timeouts, and do more retries. To this end, I have moved timeout values to #define constants in lib/sio/sio.h
The N: handler is being debugged, lots of work needing to be done there. OPEN works now, after a complete rewrite of the device spec tokenizer. Other operations currently fail due to stack smashing. I need to re-think how buffers are passed between protocol functions. Any insight anyone can offer for this, please check out the code and dip into sio/network* I did write a theory of operation in the wiki, if anyone is interested.
This is the muck of the project, we’ve done the huge flurry of “ain’t it cool?!” demos, and now we’re rolling up our sleeves, and working through the mix of technical debt and functionality testing. Not to mention writing unit tests 🙂
-Thom
Status für 2020-03-14:
@jeffpiep arbeitet hart an der Implementierung der Atari 1020 Plotter-Emulation. Diese Emulation ist insofern einzigartig, als die Ausgabe nicht als PDF, sondern als SVG erfolgt.
Es gibt noch einige weitere Tester von ESP32-Boards, und es kommen Fehlerberichte herein.
Die TNFS-Dateisystemimplementierung sendet versehentlich Erfolge zurück, wenn alle Wiederholungsversuche erschöpft sind. Das kommt von einer inkonsistenten Fehlanpassung der Rückgabewerte, die passierte, als wir den Code zur Verwendung der Standard-Arduino-FS-API portierten. Hoppla.
Zusätzlich müssen die TNFS-Wiederholungszeiten weiter abgestimmt werden, da es derzeit mehr Wiederholungsversuche gibt, als in der SIO-Zeitüberschreitung, die vom Betriebssystem für die meisten Plattenoperationen vorgesehen ist (5 Wiederholungsversuche, 5000ms, 25 Sekunden, im Vergleich zu 15 Sekunden für das Betriebssystem). Zu diesem Zweck habe ich die Zeitüberschreitungswerte in #define constants in lib/sio/sio.h verschoben.
Der N:-Handler wird gerade debuggt, es muss noch viel Arbeit geleistet werden. OPEN funktioniert jetzt, nach einem kompletten Neuschreiben des Tokenizers der Gerätespezifikation. Andere Operationen scheitern derzeit aufgrund von Stack-Zerstörungen. Ich muss neu überdenken, wie die Puffer zwischen den Protokollfunktionen übergeben werden. Jeder, der einen Einblick in diese Problematik geben kann, möge sich bitte den Code anschauen und in sio/network* eintauchen. Ich habe eine Theorie der Funktionsweise im Wiki geschrieben, falls es jemanden interessiert.
Das ist der Dreck des Projekts, wir haben die große Aufregung der "Ist das nicht cool?!"-Demos hinter uns gebracht, und jetzt krempeln wir die Ärmel hoch und arbeiten uns durch die Mischung aus technischer Verschuldung und Funktionstests. Ganz zu schweigen vom Schreiben von Unit-Tests 😀
Sleeπ
von tschak909 » Di 17. Mär 2020, 06:08
https://www.youtube.com/watch?v=Bs3mwpqh718
Sleeπ
von tschak909 » So 22. Mär 2020, 01:18
Ich habe die letzte Woche damit verbracht, den TNFS-Code zu überarbeiten, um ihn zu vereinfachen und einen einzigen Code-Pfad für das Senden von Paketen, den Empfang von Antworten und die Behandlung von Timeouts bereitzustellen. Dadurch konnte ich besser sehen, was passierte, und die Wiederholungslogik in den letzten anderthalb Tagen ändern, um sie robuster zu machen, indem ich ein Testnetzwerk verwendete, das großzügig von einem Benutzer bereitgestellt wurde, der sein eigenes #FujiNet aufgebaut hat!
Weitere Statusberichte werden bald folgen! https://www.youtube.com/watch?v=ULk2Vig7Gts
Sleeπ
von tschak909 » So 22. Mär 2020, 19:50 Für jeden, der einen Beitrag leisten möchte, ist eine weitere einfache Erweiterung erforderlich, um die TNFS-Netzwerkleistung zu verbessern, wenn der Cache ausgeschaltet ist (z.B. während der Entwicklung):
Angesichts einer Sektornummer, die in sio_read() kommt: https://github.com/FujiNetWIFI/atariwifi/blob/master/platformio/FujiNet/lib/sio/disk.cpp#L44
Bestimmen Sie, ob der zu lesende Sektor der nächste Sektor ist. Wenn ja, NICHT SEHEN, sonst führen Sie einen Suchlauf durch.
Die Sektorgröße muss ebenfalls berücksichtigt werden (die ersten drei Sektoren sind 128 Bytes groß, 256-Byte- oder 512-Byte-Sektoren werden derzeit nicht berücksichtigt).
Bei TNFS wird dadurch eine Round-Trip-Kommunikation entfernt und der Netzwerkzugang beschleunigt.
Sleeπ
von tschak909 » Mo 23. Mär 2020, 06:29 @jeffpiep has been hard at work implementing the unique sideways printing mode present on the Atari 820. Due to the unique orientation, it's implemented as a custom sideways font. Shown here is actual printed output vs the emulated PDF.
https://cdn.discordapp.com/attachments/655893902380761091/686342961222647808/89120424_10216139221173624_6141993861108465664_o.png
https://cdn.discordapp.com/attachments/655893902380761091/691476062886035486/unknown.png
Sleeπ
von tschak909 » Mo 23. Mär 2020, 21:37
It is a Raspberry Pi 3, inside a FLiRC case, with 64GB of flash, running Raspbian Lite, and the tnfsd software as a systemd service. I am powering it off one of the USB connectors on my power strip.
Total setup time: 30 minutes.
Bild
Instructions to set up, are here: https://github.com/FujiNetWIFI/atariwifi/wiki/Setting-up-TNFS-on-a-Raspberry-Pi
Sleeπ
von tschak909 » Do 26. Mär 2020, 19:38 Statusbericht 2020-03-26:
für Codierer, die nach einem Projekt oder einer Möglichkeit zur Hilfeleistung jagen: Ich könnte wirklich etwas Hilfe bei der Implementierung der ATX-Unterstützung gebrauchen, da ich damit beschäftigt bin, andere Teile des Codes zu unterstützen.
Ich habe die letzte Woche damit verbracht, den TNFS-Code durchzuarbeiten:
Rick Lopez hat am R:-Code gearbeitet, ihn auseinandergenommen, um ihn zu verstehen, und Verbesserungen vorgenommen. Seine aktuellen Experimente nehmen den Altirra R:-Handler und betten ihn in die #FujiNet-Firmware ein, um ihn per Typ-1-Abfrage weiterzugeben. (Wir haben die Erlaubnis von @phaeron) Verbesserungen der Pufferung werden auch versucht, die charakteristisch kleinen RX-Puffer zu kompensieren, die der Atari während des gleichzeitigen Betriebs der meisten MODEM-Programme angibt, um die meisten Modemprogramme dazu zu bringen, mit höheren Geschwindigkeiten arbeiten zu können. Eine Idee, die ich hier vorgeschlagen habe, ist, den R:-Handler so zu modifizieren, daß er vor dem STREAM-Befehl einen zusätzlichen Befehl ausgibt, der die Größe der angeforderten IOCB-Pufferlänge zurückgibt. Dieser kann als sekundärer Puffer verwendet werden, der nur gefüllt wird, wenn er geleert wird, um die Verbindung auch bei höheren Baudraten zu drosseln, wenn der Puffer viel zu klein ist, um höhere Übertragungsraten zu bewältigen.
Wir hacken uns weiter durch den Schlamm 🙂
Übersetzt mit http://www.DeepL.com/Translator (kostenlose Version)
2020-03-26 Status Report:
to coders itching for a project or a way to help: I really could use some help trying to implement the ATX support, as I am busy trying to shore up other parts of the code.
I spent the last week working through the TNFS code:
Rick Lopez has been working on the R: code, taking it apart to understand it, and making improvements. His current set of experiments are taking the Altirra R: handler and embedding it into #FujiNet firmware to be passed across via Type 1 poll. (We have permission from @phaeron) Buffering improvements are also being tried to compensate for the characteristically small RX buffers specified by the Atari during concurrent mode by most MODEM programs, in an effort to get most modem programs to be able to work at higher speeds. An idea I proposed here is to modify the R: handler to emit an additional command before the STREAM command which returns the size of the requested IOCB buffer length. This can be used as a secondary buffer, only filled when drained, to throttle the connection even at higher baud rates when the buffer is much too small to handle higher transmission rates.
We hack onward through the mud. 😀
Sleeπ
von tschak909 » Mo 30. Mär 2020, 00:42
The CONFIG program now has an info screen that shows network information, like the FCONFIG program in fnc-tools.
Sleeπ
von tschak909 » Di 31. Mär 2020, 17:25 Thank you all for the wonderful write up in the latest ABBUC newsletter. 🙂
-Thom
Sleeπ
von tschak909 » Sa 4. Apr 2020, 21:02
https://www.youtube.com/watch?v=sTZibzlbPTc
Sleeπ
von JoSch » Mo 6. Apr 2020, 09:13 Hi.
Can RespeQt use this 822 font? How is the license for the font?
Bye Jochen.
Sleeπ
von JoSch » Mi 8. Apr 2020, 12:05
tschak909 hat geschrieben:
*Then you have my permission to pull the font data from the FujiNet repo.
-Thom*
Thanks.
Bye Jochen
PS: We use a 1020 font, someone posted on AA. I got his permission to use it with RespeQt. Could be something for your 1020 emulation.
Sleeπ
von tschak909 » Sa 18. Apr 2020, 04:00 On the N: device, With aux2 set at open, this specifies that EOL translation should be done for input and output. There are currently four values:
This works across all protocols, and is demonstrated here by doing http GET fetch of an nginx title page: https://www.youtube.com/watch?v=ZrbIap_f0z8
Currently working on getting headers to work. From the user's perspective, this will be a multi-step process, where for e.g. a GET, you:
Other verbs, like POST will work similarly. You OPEN, you set your headers you want to send, specify any you want to recieve, PRINT your post data, get a STATUS which will get you the # of bytes of the response, then GET your response and CLOSE.
This is complex, yes, but it will allow for the whole of HTTP to be mapped cleanly onto the Atari I/O system.
Auf dem N:-Gerät wird bei geöffnetem aux2 festgelegt, dass die EOL-Übersetzung für die Ein- und Ausgabe durchgeführt werden soll. Derzeit gibt es vier Werte:
Dies funktioniert über alle Protokolle hinweg und wird hier anhand des http GET Fetch einer nginx-Titelseite demonstriert: https://www.youtube.com/watch?v=ZrbIap_f0z8
Derzeit arbeiten wir daran, die Header zum Funktionieren zu bringen. Aus der Sicht des Benutzers wird dies ein mehrstufiger Prozess sein, bei dem z.B. für einen GET, Sie:
Andere Verben, wie POST, funktionieren ähnlich. Sie OPEN, Sie setzen Ihre Header, die Sie senden wollen, geben an, welche Sie empfangen wollen, DRUCKEN Ihre Postdaten, erhalten einen STATUS, der Ihnen die Anzahl der Bytes der Antwort liefert, dann GET Ihre Antwort und CLOSE.
Das ist komplex, ja, aber es wird es ermöglichen, das gesamte HTTP sauber auf das Atari-E/A-System abzubilden.
-Thom
Sleeπ
von tschak909 » Sa 18. Apr 2020, 17:36 Apologies, as was pointed out by Stefan, I made a typo:
Thank you for pointing out the flub on my part. 🙂
-Thom
Sleeπ
von tschak909 » So 19. Apr 2020, 04:37
(lest you thought we were exaggerating) 😉
(damit Sie nicht denken, wir würden übertreiben) 😉
Sleeπ
von tschak909 » Sa 25. Apr 2020, 02:18
Sleeπ
von tschak909 » Mo 27. Apr 2020, 00:24
Sleeπ
von JoSch » Di 28. Apr 2020, 09:19 Thom, I feel you.
As much as I want to help, RespeQt has more than enough work to do. So for the time being, I will work on RespeQt.
Bye Jochen
Sleeπ
von tschak909 » Mo 4. Mai 2020, 03:25
Sleeπ
von tschak909 » Di 12. Mai 2020, 23:10
Here is some 1025 printer output from Atari Macro Assembler (AMAC) https://drive.google.com/file/d/1bpZHgQDwg4bRCeQJ1fTD6RWPanICwE5R/view
In contrast here is the same output from the Atari 1027 letter quality printer emulation. https://drive.google.com/file/d/1Hli-U7aMzv9azkf5v546gO37DDVqNBhz/view
Sleeπ
von JoSch » Mi 13. Mai 2020, 11:02 Looks really good.
Sleeπ
von nortobor » Do 14. Mai 2020, 20:37
Im ABBUC-MAG 140 gab es auf Seite 16 "Die ersten Schritte". Ich wollte das ausprobieren ESP32 programmiert, Kabelverbindung hergestellt und an den ATARI angeschlossen er bootet von ESP32 versucht zu "scannen" aber dann "FUJINET NAK!" Das Verbindungskabel ATARI-SIO Splitter ist voll belegt Im Artikel war dann noch angegeben "für einige Tests ....zusätzliche Verbindungen". Als habe ich SIO PIN 1,2,8,9,und 13 angeschlossen ------gleiches Ergebnis. im ESP ist "multilator-rev2.ino" Was habe ich übersehen ????? Wer hat das so schon mal aufgebaut????? :goteam:
In ABBUC-MAG 140 there were "The first steps" on page 16. I wanted to try it out ESP32 programmed, cable connected and connected to the ATARI it boots from ESP32 tries to "scan" but then "FUJINET NAK! The connection cable ATARI-SIO splitter is fully occupied In the article was then still indicated "for some tests ... additional connections". So I connected SIO PIN 1,2,8,9,and 13 ------same result. in ESP is "multilator-rev2.ino" What did I miss? Who built this place before?????
Translated with http://www.DeepL.com/Translator (free version)
:bitbyter:
Sleeπ
von tschak909 » Do 14. Mai 2020, 20:50 Am not the hardware guy, but seeing as you have other devices on the bus, and the fact that I do not see diodes, you're not properly bus-isolated.
The latest schematics are here: https://github.com/FujiNetWIFI/fujinet-hardware/tree/master/Schematics
-Thom
Sleeπ
von nortobor » Do 14. Mai 2020, 21:03 Für meine ersten Versuche mit FUJI-NET habe ich nur den ESP32, also keine anderen Geräte. Der ESP bootet ja die config.atr
For my first attempts with FUJI-NET I only have the ESP32, so no other devices. The ESP boots the config.atr
Sleeπ
von tschak909 » Do 14. Mai 2020, 21:08 I would also highly recommend doing the PLATFORM.IO bring-up, as this is what we are using for production code: https://github.com/FujiNetWIFI/atariwifi/wiki/Board-Bring-up-for-PLATFORM.IO-code
(yes, this project is moving very fast)
-Thom
Sleeπ
von Montezuma » Do 14. Mai 2020, 21:22
nortobor hat geschrieben:
*Für meine ersten Versuche mit FUJI-NET habe ich nur den ESP32, also keine anderen Geräte.
Der ESP bootet ja die config.atr
For my first attempts with FUJI-NET I only have the ESP32, so no other devices.
The ESP boots the config.atr*
Schau mal, ob Du alles so gemacht hast, wie auf der WIKI Seite beschrieben ist:
https://github.com/FujiNetWIFI/atariwifi/wiki/Board-Bring-Up
Es werden diverse ESP32 Module von Arduino IDE unterstützt. Manche sind erst sichtbar, nachdem sie mit dem Board Manager installiert sind. Ich war erfolgreich mit "ESP32 Dev Module".
Für multilator-rev2.ino reichen folgende Verbindungen: - Masse - Data Out - Data In - Command Line wenn ESP32 über USB angeschlossen ist.
Sleeπ
von nortobor » Do 14. Mai 2020, 23:42 Montezuma schrieb. Für multilator-rev2.ino reichen folgende Verbindungen: - Masse - Data Out - Data In - Command Line wenn ESP32 über USB angeschlossen ist.
Na "Gott sei Dank" kann ich das Kabelgewirr etwas entschlacken. ESP DEV Module habe ich eingestellt und werde das ganze noch mal "hochladen"
Noch was am Rande -(und das übersetze ich bewußt nicht in engl)---Montezuma geht hier wenigstens darauf ein, um ABBUCer zu ermutigen, FUJI-NET zu testen --- ansonsten habe ich den Eindruck, hier ist eine "abgeschlossene Vereinigung" Der ABBUC ist ein Computerclub seit 1985 mit dem Ziel "ABBUC der Computerclub zum mitmnachen". Montezuma mach weiter so und vielleicht ist im MAG 141 wieder ein Artikel von dir, der es ermöglicht, daß viele im ABBUC dazu angeregt werden, nicht nur fertige Lösungen zu "kaufen" sondern zu testen zu probieren zu experimentieren. :goteam
Sleeπ
von tschak909 » So 17. Mai 2020, 22:50
Sleeπ
von tschak909 » Di 19. Mai 2020, 20:23 This is a quick video showing file upload to FTP using the N: device courtesy of SpartaDOS. #ATARI8BIT #FujiNet
Sleeπ
von tschak909 » Fr 22. Mai 2020, 07:27 I Have been steadily refining the CHDIR functionality for the N: device, and its "wrapper" NCD.
(1) if the last element in the path is a folder, remove it, thereby going up a directory
(2) if the last element in the path is a file, remove the file, and stay in its directory.
and you then NCD'd to stuff/collections
your path would be:
ftp://FTP.PIGWA.NET/stuff/collections/
then NCD / will cause it to revert to
There is an interesting side-effect to this, if the last absolute URL provided to NCD has path elements in it, they are retained as the "initial path" so the / will not remove them.
This has produced a usable pair of tools in NCD and NPWD that can comfortably move around networked filesystem directories, regardless of the underlying DOS, which simply does not care.
Of course, since this isn't actually a "Change directory" call, but rather a "set prefix" call, you can chdir to a file directly and reference it as N:, e.g.
NCD files/foo.com
This allows you to use DOSes with broken copy commands (e.g. OS/A+ or DOS XL), or DOSes that explicitly penalize you for thinking that any device other than "D:" can possibly have a file system! (Looking at you, Atari DOS 3)
Since the CIO call for CHDIR is 0x2C (aka XIO 44), this is compatible with SpartaDOS, and thus, you can use CWD under SpartaDOS 3.2, or CD under SpartaDOS X to accomplish exactly the same thing, with the exact same behavior.
and of course, since this is an XIO call, it can be done from BASIC, without needing to load NCD.
I have been spending hours now loading random files into BASIC, Action! MAC/65 etc from the ANTIC! archives, and having way too much fun doing so. 😉
Sleeπ
von tschak909 » Mo 1. Jun 2020, 03:51
Sleeπ
Hallo,
die Kabel sind gekauft, also Standart für diese Steckbretter (ca. 25 cm lang), Die Stifte vom Splitter sind etwas stärker, daher gehen sie ziemlich stramm rauf. Ich lasse sie aber so, da ich mit dem SIO noch andere Versuche und Messungen durchführe.
Versuche mit FUJI habe ich aber aufgegeben , autorun.atr lädt (also Kabelverb. o.k.) aber keine Anzeige von WIFI-Netzwerken (multilator-rev2.ino)
Sleeπ
von tschak909 » Mo 8. Jun 2020, 06:04 One last video for this weekend, showing where things are with regards to high speed N, that is speeds above standard SIO rate on the N: device. It is possible if you have an appropriate high speed patch, but it still needs work...as you will see... https://youtu.be/IEMGwmkidWQ
Ein letztes Video für dieses Wochenende, das zeigt, wo die Dinge in Bezug auf die hohe Geschwindigkeit N stehen, d.h. Geschwindigkeiten über der Standard-SIO-Rate auf dem N:-Gerät. Es ist möglich, wenn Sie ein entsprechendes Hochgeschwindigkeits-Patch haben, aber es muss noch bearbeitet werden... wie Sie sehen werden... https://youtu.be/IEMGwmkidWQ
Sleeπ
von tschak909 » Mi 10. Jun 2020, 02:50
Sleeπ
von skriegel » Di 16. Jun 2020, 08:02 Mist, da war ich wohl zu langsam. Aber da wird ja sicher noch mehr kommen, oder? 🙂
Sleeπ
von nortobor » Do 18. Jun 2020, 14:25 Hallo tschak909, vielen Dank für die lange Erläuterung in deutsch für unser ABBUC-Forum. Bin an dem FujiNet sehr interessiert und habe ja auch einige, leider erfolglose, Versuche unternommen (nach dem Artikel im ABBUC-Magazin von Montezuma). Mir geht es nicht vorrangig um eine fertige Hardware, sondern auch um die Verbindung ATARI XL/XE (8-Bit Technik aus den 1980 zigern) mit Technik heutiger Zeit- 2020.
Nicht so gut fand ich den Inhalt der Sätze --"Aufrufe an die Arduino-Bibliothek zu entfernen und sie durch Aufrufe an das ESP-IDF-Framework zu ersetzen." und "Die harte Arbeit an der Infrastruktur, um uns von den Arduino-Abhängigkeiten zu befreien, hat sich ausgezahlt" Es ist natürlich euer Projekt und ihr seid sicher erfolgreich, das zeigt ja auch, daß die ersten 50 Bestellungen schnell weg waren. Mir wäre natürlch eine "Arduino-Abhägigkeit" lieber.
Wünsche Euch viel Erfolg und hoffe, daß hier im deutschem ABBUC-Forum sich mehr für diese Projekt interssieren. :goteam:
Hello chak909, thank you very much for the long explanation in german for our ABBUC-Forum. I am very interested in the FujiNet and have made some, unfortunately unsuccessful, attempts (after the article in the ABBUC magazine of Montezuma). I am not primarily interested in a finished hardware, but also in the connection of ATARI XL/XE (8-bit technology from the 1980s) with technology of today's time - 2020.
I didn't like the content of the sentences -- "remove calls to the Arduino library and replace them with calls to the ESP-IDF framework" and
"All the hard work we put into the infrastructure to free us from the Arduino dependencies has paid off" It is of course your project and you are certainly successful, which also shows that the first 50 orders were quickly gone. Of course, I'd prefer an "Arduino addiction".
Wish you good luck and hope that more people are interested in this project here in the German ABBUC-Forum.
Sleeπ
von Mathy » Fr 19. Jun 2020, 00:57 Hallo Leute
Bin mir noch nicht sicher ob Ich diese Hardwarelösung haben will oder zB. die von Dropcheck/Lenore (oder beide), aber wir könnten doch eine Sammelbestellung organisieren, oder? Mit Auslieferung auf der Fujiama.
Tschüß
Mathy
Sleeπ
von tschak909 » Mi 8. Jul 2020, 20:57
Everything is mostly set up at this point, and I've resumed both my day job and work on IRATA.ONLINE and #FujiNet. The rest of this post deals with #FujiNet.
I have had to get a couple of purchases with the funds that have come in from Patreon, thanks to all that have contributed:
My development laptop (TMA-1) is suffering from thermal battery expansion which has warped my case. $250 from the Patreon was used to submit a warranty service request for on-site service to replace both my battery (which is four years out of warranty) and the bottom battery cover which has been damaged. This will happen in the next few days, as soon as my Dell representative confirms my on-site appointment.
My capture device which was being used to record all the various #FujiNet videos has died, and I decided to replace it with a proper capture device that can plug into my RetroTink 2X upscaler, an Elgato HD 60 S+, for $216 all in.
I am in the process of continuing on N: development. The code is now self-relocatable, thanks to the ultd example provided by Jon Halliday (@flashjazzcat), the N: code now runs successfully under SpartaDOS, and is smaller than the ACTION! based relocator, as well as being more efficient.
At this point, N: needs: * An implementation of BINARY LOAD for both MyDOS and SpartaDOS. * Make ?DIR work in SpartaDOS * Implement directory listing for WEBDAV (HTTP/S) * Implement the rest of 8.3 to long filename translation. This is difficult because we need to implement a sort of filename cache. * (maybe) deal with the fact that SpartaDOS upper-cases ALL CP input. grrr.
Furthermore, N: also needs functional XML and JSON parsers that we can embed and interface to. This is, by and large, the last 20% of N: development, which will take a significant chunk of time, along with debugging every possible combination of DOS/DUP that can use the N: device.
More to come, but I wanted to give everybody an update over the last two weeks! -Thom
Im Moment ist alles weitgehend eingerichtet, und ich habe sowohl meinen Tagesjob als auch meine Arbeit an IRATA.ONLINE und #FujiNet wieder aufgenommen. Der Rest dieses Beitrags befasst sich mit #FujiNet.
Mit den Geldern, die aus Patreon eingegangen sind, musste ich einige Käufe tätigen, dank all derer, die dazu beigetragen haben:
Mein Entwicklungs-Laptop (TMA-1) leidet unter thermischer Batterieausdehnung, die mein Gehäuse verformt hat. $250 von der Patreon wurden verwendet, um eine Garantieanforderung für einen Vor-Ort-Service einzureichen, um sowohl meine Batterie (die vier Jahre außerhalb der Garantiezeit ist) als auch die untere Batterieabdeckung, die beschädigt wurde, zu ersetzen. Dies wird in den nächsten Tagen geschehen, sobald mein Dell-Vertreter meinen Vor-Ort-Termin bestätigt.
Mein Capture-Gerät, mit dem all die verschiedenen #FujiNet-Videos aufgenommen wurden, ist abgestorben, und ich habe mich entschlossen, es durch ein geeignetes Capture-Gerät zu ersetzen, das an meinen RetroTink 2X Upscaler, einen Elgato HD 60 S+, angeschlossen werden kann, und zwar für $216 insgesamt.
Ich bin gerade dabei, die Entwicklung von N: fortzusetzen. Der Code ist jetzt dank des ultd-Beispiels von Jon Halliday (@flashjazzcat) selbstrelozierbar, der N:-Code läuft jetzt erfolgreich unter SpartaDOS, ist kleiner als der auf ACTION! basierende Relocator und außerdem effizienter.
An diesem Punkt benötigt N:: * Eine Implementierung von BINARY LOAD sowohl für MyDOS als auch für SpartaDOS. * Damit ?DIR in SpartaDOS funktioniert. * Implementierung der Verzeichnisauflistung für WEBDAV (HTTP/S) * Implementieren Sie den Rest der Übersetzung von 8,3 zu langen Dateinamen. Dies ist schwierig, da wir eine Art Dateinamen-Cache implementieren müssen. * (vielleicht) mit der Tatsache umgehen, daß SpartaDOS ALL CP input in Großbuchstaben schreibt. grrr.
Darüber hinaus benötigt N: auch funktionale XML- und JSON-Parser, die wir einbetten und mit denen wir eine Schnittstelle bilden können. Dies sind im Großen und Ganzen die letzten 20 % der Entwicklung von N:, was einen beträchtlichen Teil der Zeit in Anspruch nehmen wird, zusammen mit dem Debuggen jeder möglichen Kombination von DOS/DUP, die das N:-Gerät verwenden kann.
Es wird noch mehr kommen, aber ich wollte alle in den letzten zwei Wochen auf den neuesten Stand bringen!
Sleeπ
von tschak909 » Sa 18. Jul 2020, 04:06
Sleeπ
von tschak909 » So 19. Jul 2020, 02:19
Ich versuche derzeit, einige Teile des N:-Geräts zu überdenken, solange ich das noch kann (während fast niemand es tatsächlich benutzt). Das N:-Gerät besteht aus zwei Teilen: Der Handler auf dem Atari, der CIO in SIO umwandelt. Und die Firmware, die SIO in Aktionen auf dem ESP32 umwandelt. Dies ist von grundlegender Bedeutung, da SIO blockbasiert und CIO zeichenbasiert ist. Um die Diskussion vorerst zu vereinfachen, spreche ich nur über die SIO-Schicht. DIE SIO-SCHICHT: Sie können die SIO-Befehle für das N: Gerät hier sehen: https://github.com/FujiNetWIFI/fujinet-platformio/wiki/SIO-Commands-for-Device-IDs-%2471-to-%2478 SIO ist Halbduplex. Sie verarbeitet Daten jeweils nur in einer Richtung, und obwohl es in der Befehlsstruktur ein Feld gibt, das an den Atari gesendet wird, um zu sagen, wie viele Bytes übertragen werden müssen, wird dies nicht als Teil des Befehlsrahmens entweder an oder von FujiNet übermittelt, was wir für READ- und WRITE-Operationen benötigen. Die beiden Bytes AUX1 und AUX2 hingegen schon. Wir müssen also duplizieren, was im DBYT-Feld in den Feldern AUX1 und AUX2 steht, so dass sie als Teil des Befehlsrahmens erscheinen und daher von der Firmware abgefangen werden können. OPEN - stellt eine Protokollverbindung her, die Nutzlast geht an das FujiNet, und diese Nutzlast ist die N: Dateispezifikation. AUX1 wird zumindest zum offenen Modus, Bit 2 und 3 sind für Lesen und Schreiben bzw. durch den CIO reserviert, so dass wir diese spiegeln müssen. In OPEN wird AUX2 zum Modus TRANSLATION, d.h. wie übersetzen wir eine Ende-der-Zeile-Sequenz? Derzeit: 0 = keine Übersetzung, Bit 0 übersetzt CR, Bit 1 übersetzt LF, wenn also die Bits 0 und 1 gesetzt sind, dann werden CR/LF zu und von den beiden Endpunkten übersetzt. Wenn beide CR/LF übersetzt werden, wird die Sache komplizierter, denn entweder wird ein Byte HINZUFÜGEN (im Falle der Konvertierung eines einzelnen EOL-Bytes in CR/LF-Bytes) oder ein Byte UNTERZIEHEN (im Falle der Konvertierung von CR/LF-Bytes in ein einzelnes EOL-Byte). Erinnern Sie sich, dass wir im Voraus festgelegt haben, wie viele Bytes zu lesen/schreiben sind? 🙂 Wenn ein STATUS-Befehl gesendet wird, werden vier Bytes zurückgegeben. BL BH CO ER, BL und BH sind die Low- und High-Bytes der Anzahl der verfügbaren Bytes (bis zu 65535), während CO verbunden ist (1 = verbunden, 0 = getrennt), und ER der Fehlercode ist, der an den CIO-Handler übergeben wird. Nehmen wir also an, wir lesen Daten von einem HTTP-Endpunkt: OPEN N:http://www.google.com/ und in einer Schleife:
STATUS();
while (status.bytesVerfügbar>0)
{
READ(buf); // Verringert die Anzahl der verfügbaren Bytes.
verarbeiten(buf);
STATUS();
}
Als Teil der Schleife führen wir also einen Status durch, um zu sehen, wie viele Bytes verfügbar sind. Der WEG, auf dem ich mich derzeit mit der Übersetzung befasse, besteht darin, sie buchstäblich zu fälschen, wobei die gleiche Anzahl von Bytes beibehalten wird: Wenn CR, dann wird EOL in CR übersetzt, CR wird in EOL übersetzt. Wenn LF, dann wird EOL in LF übersetzt, LF wird in EOL übersetzt. Wenn CR/LF, dann wird der Sendepuffer um 1 vergrößert (und die Länge des Sendepuffers um 1 erhöht), und EOL wird zu CR, wobei LF unmittelbar danach eingefügt wird, während beim Empfang CR zu einem SPACE wird, während LF zum EOL wird. Dadurch braucht der Empfangspuffer seine Größe nicht zu ändern. Ist dies eine schlechte Idee? Eine Variante davon ist die Übersetzung von Verzeichnisdaten für Netzwerk-Dateisystem-Endpunkte. Sie können im OPEN-Aufruf angeben, ob Sie das Verzeichnis lesen möchten (aux1=6), aber jedes Netzwerkprotokoll führt ein Dateiverzeichnis anders aus und stellt eine Liste von Objekten in einer völlig anderen Syntax dar. Während wir in einigen Fällen die Daten so anzeigen könnten, wie sie sind (z.B. von FTP), erwarten eine Reihe von Atari-Programmen (wie z.B. (AtariWriter) etwas, das wie das Atari-DOS-Diskettenverzeichnis aussieht. Aus diesem Grund verwenden selbst DOS-Systeme wie SpartaDOS standardmäßig ein Verzeichnisverzeichnis, das wie Atari-DOS aussieht. Das bedeutet, dass es derzeit Code in der Firmware gibt, um die Verzeichnisdaten, die von einem Protokoll zurückkommen, in etwas zu übersetzen, das wie ein DOS-2-Verzeichnis aussieht. Gegenwärtig bedeutet dies auch, dass das IST-Lesen von Verzeichnisdaten im STATUS-Aufruf erfolgt, wobei die Daten in den Empfangspuffer geleert werden, während READ den RECEIVE-Puffer auf den Atari leert und ihn anschließend für den nächsten Statusaufruf löscht. Damit stellt sich die Frage: Gibt es einen besseren Weg? Gegenwärtig besteht der CIO-Handler auf dem Atari aus etwa 1000 Byte Code, mit 256 Byte Puffer darüber (also 1,3K im gesamten Speicherverbrauch). Er ist klein, weil alles auf dem ESP passiert, und der Handler alles durchlässt (mit einigen kleinen Ausnahmen). Die CR/LF-Übersetzung könnte z.B. im CIO-Handler auf den Atari verschoben werden, wobei etwa 40 oder so Bytes Code hinzugefügt werden, aber wie sollten wir Dinge wie die Dateiverzeichnis-Übersetzung handhaben? Ist die Handhabung im Statusaufruf der einzig vernünftige Weg, dies wirklich zu tun? Gedanken?
Sleeπ
von tschak909 » So 19. Jul 2020, 05:10
@jeffpiep hat es wieder getan! OkiMate 10-Unterstützung wurde der Druckeremulation hinzugefügt, komplett mit Farbe!
-Thom
Sleeπ
von tschak909 » Mo 20. Jul 2020, 04:07
Sleeπ
von Mathy » Mi 22. Jul 2020, 00:26 Hallo Holger, Leute
Lenore/Dropcheck arbeitet momentan u.A. am "Atari SIO2IO Externally Housed Combo board":
"This project is still in the beta design phase and it’s exact specs will change. In general it will include the MIDI2SIO in/out connections by Mytek, DB25 parallel printer adapter by Supra Microprint, a basic DB9 Rverter serial port and the finished FujiNet wireless hardware project and be self powered. It should be compatible with nearly all Atari 8bit machines and be connected via a single SIO dongle. At this point it should be able to be sold either fully assembled or as a bare board with BOM."
"Kurz" zusammengefasst:
Tschüß
Mathy
Sleeπ
von Montezuma » Mi 22. Jul 2020, 17:57
tschak909 hat geschrieben:
*I really don't see the point of Dropcheck's device, as there is considerable overlap with what #FujiNet provides.
(I say this out of frustration, as they simply assumed that they knew what FujiNet was, didn't ask what it could do, much less talk to us, at all, didn't watch any of the videos to get an idea, and threw one in as an afterthought)
-Thom*
I fully agree. Lenore's device makes no sense. Overlapping functionality may only cause conflicts and missunderstanding. People will complain that things do not work, because of potencial incompatibility of the projects put together without any good reason. If I were you I would explicitely forbid to build such monsters.
Sleeπ
von tschak909 » Mi 22. Jul 2020, 18:05 I won't forbid anything, it IS a public project, and this is one of the consequences.
I'm more just disappointed and frustrated, because even after we found out that this was happening, and we went to them and tried to impart what we were going to do, they still chose to do it their way, as is their perogative...
(they = Dropcheck and Mytek btw)
-Thom
Sleeπ
von tschak909 » So 26. Jul 2020, 21:37
Sleeπ
von tschak909 » Mo 10. Aug 2020, 01:21
Sleeπ
von tschak909 » Di 25. Aug 2020, 07:08 Oscar Fowler hat hart an der Implementierung der ATX-Disk-Image-Unterstützung für kopiergeschützte Titel gearbeitet! ATX-Dateien werden als Ganzes von ihrer Quelle (Netzwerk oder lokal) zwischengespeichert, damit die Timings genau sind. https://youtu.be/0Z08VjOL548
Sleeπ
von tschak909 » Mi 9. Sep 2020, 06:27
-Thom
Sleeπ
von tschak909 » Mo 14. Sep 2020, 06:01
Sleeπ
von Sleepy » Fr 25. Sep 2020, 12:57 Danke für den Tip!
Sleepy
Sleeπ
von tschak909 » Sa 3. Okt 2020, 07:11
Sleeπ
von tschak909 » Di 20. Okt 2020, 20:31 Ich habe dem Baustein FUJI ($70) einen neuen Befehl ($DF) hinzugefügt, der bewirkt, dass der #FUJINET ein Taktsignal am CLOCKIN-Pin zur synchronen Übertragung ausgibt. Die AUX-Bytes geben die Frequenz in kHz an und werden von @mr-atari verwendet, um ein UHSIO mit einer theoretischen maximalen Rate von 440kHz zu implementieren. Ein Werkzeug in fnc-tools namens FESCLK kann die Taktrate einstellen.
Sleeπ
von tschak909 » Do 26. Nov 2020, 23:36 Hallo zusammen, ich hoffe, alle haben ein tolles Thanksgiving! Ich hatte ein paar Minuten hier, in denen ich an der #FujiNet-Firmware gearbeitet habe, bevor alle aufgetaucht sind, und wollte ein Status-Update darüber geben, woran im Moment gearbeitet wird.
Von meinem Ende aus verbringe ich den Rest des Jahres damit, N: neu zu schreiben. Die Ergebnisse fließen in diesen Zweig ein: https://github.com/FujiNetWIFI/fujinet-platformio/tree/network-rewrite
Wie Sie sehen können, gibt es derzeit über 160 Commits vor dem Master-Zweig, der zum Schneiden von Produktions-Firmware-Versionen verwendet wird, so dass dort eine Menge Arbeit geleistet wird und noch mehr zu tun bleibt. Zum jetzigen Zeitpunkt arbeiten die TCP-, TELNET- und UDP-Protokolladapter korrekt. Ich verwende die Programme netcat und dumbterm.bas, um zwischen diesen Protokolltypen umzuschalten, und ich verwende netcat auf der PC-Seite, um diese Protokolle zu testen und sicherzustellen, dass sie korrekt funktionieren.
Ich habe versucht, UDP Multicast-Unterstützung hinzuzufügen, konnte es aber nicht zum korrekten Funktionieren bringen. Ich bin sicher, dass es etwas ist, was ich auf meiner Seite falsch mache, also werde ich es in Zukunft noch einmal versuchen.
Die wichtigsten Änderungen gegenüber dem Master bestehen darin, Netzwerkprotokolle in ihre eigene Bibliothek herauszubrechen und zu versuchen, Protokollaktionen vom network.cpp-SIO-Gerät so weit wie möglich zu isolieren. Dazu gehörte, dass man sehr bewusst Fehlerbedingungen vom Protokoll an das SIO-Gerät weitergab und versuchte, so viele Wiederholungen, die sich in den verschiedenen Protokolladaptern ansammelten, so weit wie möglich zu berücksichtigen. Zu diesem Zweck gibt es nicht nur eine neue Basisklasse, NetworkProtocol, sondern auch eine sekundäre Basisklasse für Protokolle, die als Dateispeicher fungieren, NetworkProtocolFS, die Dateisystemaktionen wie Lesen/Schreiben von Dateien gegenüber Verzeichnissen, Arbeiten mit Verzeichnissen usw. hinzufügt, und vor allem die Auflösung von 8.3-Zeichen-Dateinamen in längere Dateinamen, um die Kompatibilität mit Programmen und Plattendienstprogrammen zu maximieren, die davon ausgehen, dass alle Dateinamen 8.3 sind.
Mein Ziel ist es also, die Protokolle, die zur Zeit im Master existieren, neu zu schreiben und dabei den Proof-of-Concept-Code aufzulösen, der in einigen Protokolladaptern vorhanden ist (wie z.B. FTP, das einen viel robusteren Protokoll-Zustandsautomaten benötigt! ), weiß ich nicht, wie lange das dauern wird, aber da ich für den Rest des Jahres im Urlaub bin, beabsichtige ich, so viel Zeit wie möglich auf die Implementierung dessen zu verwenden, was für N: getan werden muss, und N: hoffentlich so weit zu bringen, dass es von einem breiteren Publikum als nützliches Werkzeug und nicht nur als reine Kuriosität verwendet werden kann.
Sleeπ
Hallo Thom,
wir (Abbuc in Berlin) haben wieder ein wenig #Fujinet ausprobiert.
Die Drucker Emulation ist absolute Klasse
:jumpie::jumpie::jumpie:
Ein WLan Drucker am Atari der überzeugt.
Erstellt mit Basic
Viele Grüße
Nortobor &
Sleeπ
on Montezuma » Mi 9. Dez 2020, 22:24
Vor einiger Zeit hatte ich ein ESP32 WROVER Modul als DevKIT gekauft (~10€), aber bin erst jetzt dazu gekommen, es zu programmieren und testen.
So ein Modul hat sogar ein MicroSD Karten Slot.
Leider hat er nur 4MB Flash (statt 16MB wie die Fujinet Hardware) und andere PIN Belegung als das Original.
Das bedeutet, dass man so ein Modul nicht einfach mit dem Fujinet-Flasher Tool programmieren kann.
Dafür muss man die PIN-Zuordnung im Quellcode ändern und die Software selbst bauen.
Die notwendigen Signale (DATA IN/OUT/CMD) anschliessen und es funktioniert 🙂
Eine günstige Alternative für die jenigen, die mit dem Quellcode ein wenig umgehen können.
Sleeπ
von dl7ukk » Fr 11. Dez 2020, 23:49 Hi Marcin,
Montezuma hat geschrieben:
*Vor einiger Zeit hatte ich ein ESP32 WROVER Modul als DevKIT gekauft (~10€), aber bin erst jetzt dazu gekommen, es zu programmieren und testen.*
Glückwunsch, dass #Fujinet auch bei Dir mit dem ESP32 WROVER Modul als DevKIT funktioniert. Damit ist #FujiNet vielleicht für mehr User interessant.
Nortobor vom AiB war auch schon erfolgreich. Leider hat es da Keiner bemerkt. Aber funktionieren tut es.
Siehe hier.
Danke für Deine Unterstützung bei der Suche nach dem DevKIT!
:goteam: :goteam:
Gruß
Sleeπ
von tschak909 » Sa 12. Dez 2020, 00:38
Sleeπ
von Montezuma » Sa 12. Dez 2020, 00:50
dl7ukk hat geschrieben:
*Nortobor vom AiB war auch schon erfolgreich. Leider hat es da Keiner bemerkt. Aber funktionieren tut es.
Siehe hier.
Danke für Deine Unterstützung bei der Suche nach dem DevKIT!
:goteam::goteam:
Gruß*
Bei meinem DevKIT war IO39 als "VN" kenngezeichnet:
Die SD Karte funktioniert nicht, weil sie anders angeschlossen ist:
FUJINET KIT
IO 19 MISO IO 2 (FUJINET LED1)
IO 5 CS IO 13 (FUJINET LED3)
IO 23 MOSI IO 15 (FUJINET JTAG TDO)
IO 18 SCK IO 14 (FUJINET JTAG TMS)
Sleeπ
von dl7ukk » Mo 14. Dez 2020, 11:52 Hallo Marcin,
Montezuma hat geschrieben:
*Bei meinem DevKIT war IO39 als "VN" kenngezeichnet:*
Wofür steht VN & VP ?
Da haben wir unterschiedliche Dev_KIT gekauft. https://www.makershop.de/plattformen/arduino/ttgo-t8-esp32/ https://www.makershop.de/plattformen/d1-mini/wemos-lolin-d32-pro/
Auf die "Schnelle" kann ich die Teile leider nicht vergleichen. Aber schön dass die Auswahl da ist. 😀
*Die SD Karte funktioniert nicht, weil sie anders angeschlossen ist:*
Bei uns natürlich auch nicht 😢
Gruß
Sleeπ
von tschak909 » Mo 14. Dez 2020, 21:09
Sleeπ
von Montezuma » Mo 14. Dez 2020, 21:59
dl7ukk hat geschrieben:
*Montezuma hat geschrieben:
Die SD Karte funktioniert nicht, weil sie anders angeschlossen ist:
Bei uns natürlich auch nicht 😢*
Ich meinte, ich musste zuerst die PIN-Zuordnung im Code ändern, danach funkionierte die SD Karte.
tschak909 hat geschrieben:
*#Atari8bit the latest build of the #FujiNet firmware not only adds support for the cassette slot (so you can load cassette images, even over network!), it also fixes the long standing ticket #371 MODEM hangs! :)[https://youtu.be/KVRjF560IDQ](https://youtu.be/KVRjF560IDQ)*
Toll 😀
Sleeπ
von Mathy » Do 17. Dez 2020, 03:25 Hallo Leute
Die FujiNet Hardware gibt es bis jetzt nur in der 1.0 Version zu kaufen. Momentan wird die Hardwareversion 1.3 getestet (nicht von mir!).
Tschüß
Mathy
Sleeπ
von Natuvel » Mo 21. Dez 2020, 18:11 Bräuchte mal bisschen Hilfe... Habe heute wieder bisschen mit dem Fujinet beschäftigt, auch mit der nicht konstanten Verbindung zu den Servern und da habe ich auf AA den Tipp mit dem Ping gelesen. Und siehe da, die Verbindung zum FujiNet ist absolut instabil. Den Log habe ich angehängt:
Ping wird ausgeführt für 192.168.178.79 mit 32 Bytes Daten:
Antwort von 192.168.178.79: Bytes=32 Zeit=1239ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2686ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2378ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2893ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2234ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1035ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=5ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=204ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=391ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=3125ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=93ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=2441ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3463ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1771ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2492ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1986ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1376ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1995ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=80ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=58ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=22ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=26ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1733ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1928ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1944ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1944ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=133ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=109ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=100ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=93ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=84ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=81ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=81ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=65ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=56ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=51ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=28ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3301ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=884ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=4ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1275ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1249ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=1367ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=37ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=552ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=330ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2474ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=90ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=3253ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=81ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=2565ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=1175ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=54ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=57ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=69ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=48ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=47ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=35ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=59ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=111ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=2ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=388ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=94ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=47ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=114ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=20ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=29ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=39ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=50ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=56ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=2941ms TTL=255
Antwort von 192.168.178.79: Bytes=32 Zeit=3ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.79: Bytes=32 Zeit=92ms TTL=255
Wenn ich eine Diskette von meinem TNFS Server lade, stockt das Laden immer genau in dem Moment, wenn keine Verbindung besteht. Das gleiche Verhalten zeigt das FujiNet, wenn ich es am PC direkt angeschlossen habe, also kann ich den Atari ausschließen. Was kann ich noch ausprobieren bevor ich jetzt den Verkäufer kontaktiere?
Viele Grüße Jochen
Sleeπ
von Mr Robot » Di 22. Dez 2020, 19:27 Es könnte einfach sein, dass Sie die Box neu gestartet haben und die Konfigurationsänderung, die Sie vorgenommen haben, nicht wirklich einen Unterschied gemacht hat. Mein Router muss ab und zu neu gebootet werden, da er sonst wirklich schlechte Verbindungen und langsame Antworten liefert.
--- EN ---
It could just be that you rebooted the box and the config change you made didn't really make any difference. My router needs rebooting now and then or it starts giving really crappy connections and slow responses.
Sleeπ
von tschak909 » Fr 25. Dez 2020, 04:50
Sleeπ
von Bernd » Fr 15. Jan 2021, 00:58 Im Schaltplan ist mir etwas aufgefallen. Der Ausgang von U4 (74LS07) an Pin6 SIO_DATAIN ist ein Open Collector und benötigt noch ein Pullup Widerstand mit 4,7k an +5V. Je nach Leitungslänge und bei Pokey Divisor 0 wird das Signal verformt, da die Busterminierung nicht erfolgt. Der Abschlusswiderstand sorgt für ein Rechtecksignal. @Roland: Kannst du die Info weiterleiten? Danke vorab...
Sleeπ
von luckybuck » Fr 15. Jan 2021, 21:30 Ich ertrinke z. Z. in Arbeit... Danke Dir.
Sleeπ
von Bernd » Mo 18. Jan 2021, 00:57
tschak909 hat geschrieben:
*Coming soon: CP/M support 🙂*
https://www.youtube.com/watch?v=hret9k2afys&feature=youtu.be
Incredible! 😲 In the 80s I was still working under CP/M myself. When I find the time, I like to test it.
Sleeπ
von luckybuck » Mo 18. Jan 2021, 05:57 That is sooooo amazing! 🙂))
A giant leap for the community!
:goteam: Thom :goteam:
Sleeπ
von tschak909 » Di 19. Jan 2021, 05:36
Sleeπ
von tschak909 » Di 2. Feb 2021, 06:35
Sleeπ
von tschak909 » Sa 6. Feb 2021, 18:56 deep-breath
That's not the problem you're having. The issue you're having has to do with high-speed. When using these other DOS, you MUST go into the web admin (by default at http://fujinet/) and turn down the HSIO divisor to something like 9.
I use an Ultimate 1MB which loads its own HSIO routines, which do not have these issues. -Thom
Sleeπ
Ich hab ein "funktionierendes" FujiNet zusammengebaut. Die Tests verliefen bis auf EINE Ausnahme gut. (manche Tests erst beim zweiten Mal)
Das Drucken ins PDF funktioniert augenscheinlich nicht. Egal ob aus Printshop oder aus als Dos copy, die PDFs sind nicht zu öffnen, sie sind angeblich defekt. (Hänge ich gleich an)
Ist das Feature zur Zeit noch etwas wackelig auf den Beinen, oder liegt es wahrscheinlich an meiner Bastelei?
Stefan
Ich habe mit FujiNet V1.3 keinerlei Probleme mit Print Shop oder The Last Word nach PDF zu drucken, mit V1.5 habe ich es noch nicht getestet.
Ich habe es gerade noch mal getestet. Mit LastWord konfiguriert auf AT1029 und natürlich auch Fujinet auf 1029 eingestellt, hat es sofort funktioniert.
Weiß der Geier, warum es gestern nicht geklappt hat. Ich habe mein WLAN im Verdacht. Teste die Tage mal mit einem Gast-Wlan ausschließlich für 2.4Ghz. Einziger Nachteil, ich musste hin und wieder auf dieses Netz umschalten um das Fujinet von außen konfigurieren zu können, oder die Daten/Ausdrucke herunterzuladen.
Stefan
Stefan Both schrieb: Das Drucken ins PDF funktioniert augenscheinlich nicht. Egal ob aus Printshop oder aus als Dos copy, die PDFs sind nicht zu öffnen, sie sind angeblich defekt.
Ich habe mein Fujinet jetzt auch bekommen. Cooles Teil... 🙂
Ich habe als Drucker erst mal den ATASCI html (ganz unten in der Liste) genommen. Das Druckbild entspricht exakt dem des ATARI mit grafischem Zeichensatz, "druckt" allerdings kein PDF, sondern macht ein neues Fenster mit dem Ausdruck auf. Diesen kann man vom Browser aus dann als PDF speichern.
Das Problem mit den "richtigen" Druckern (korruptes PDF) hatte ich auch, bin der Sache aber noch nicht auf den Grund gegangen.
Sleeπ
Sleeπ schrieb: Das Problem mit den "richtigen" Druckern (korruptes PDF) hatte ich auch, bin der Sache aber noch nicht auf den Grund gegangen.
Lies bitte den Beitrag über Deinem ! Es hatte dann doch "irgendwie " funktioniert.
Stefan
